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Procede de transmission de flux de donnees, flux de donnees, serveur, 
terminal, procede de reception et utilisation correspondents. 

Le domaine de T invention est celui de la transmission de donnees, sous la 
forme d'un ou plusieurs flux de donnees constitues chacun d'unites de flux 
5 elementaires. Plus precisement, Tinvention concerne P optimisation du traitement 
de ces unites de flux elementaires, lorsque celles-ci sont dependantes de, ou Her a, 
une ou plusieurs autres unites de flux. 

Lorsqu'un signal, par exemple de type multimedia, est transmis sur un 
canal unique et de fagon synchrone, le traitement d'une unite de flux ne pose pas, 
10 ou peu, de probleme. Les donnees necessaires ont ete re$ues precedemment. 

Cela n'est pas le cas, en revanche, dans des systemes asynchrones, pouvant 
mettre en ocuvre plusieurs canaux de transmission, et/ou plusieurs serveurs 
distribuant chacun une partie du signal utile. C'est par exemple le cas de la 
transmission, ou de la diffusion, sur un reseau type IP. 
15 Dans ce cas, il arrive que Ton regoive une unite de flux qui est sensee en 

completer d' autres, qui n'ont pas ete re?ues. II peut par exemple s'agir de donnees 
d'enrichissement de donnees d'un niveau hierarchique superieur, les donnees 
etant codees a l'aide d'un codage hierarchique (un flux pouvant aiors 
correspondre a un niveau hierarchique donne). Le traitement des donnees 
20 d'enrichissement va alors donner un resultat aleatoire, conduisant en general a une 
forte degradation du signal restitue, voire a un blocage complet du decodeur. 

L'art anterieur en matiere de synchronisation multimedia est represente 
essentiellement par les protocoles de transport bases sur RTP et par MPEG-4 
(Synchronization Layer). Dans Fapproche utilisee, les mecanismes de 
25 synchronisation ont ete principalement conf us pour synchroniser temporellement 
un flux audio et un flux video, afin qu'ils soient presentes sans decalage. Ces 
informations etaient vehiculees au moyen d'un systeme d'estampillage temporel 
(une horloge de reference, des estampilles de decodage et de presentation). 

Avec Pavenement de codages hierarchiques, ou differents niveaux 
30 d'enrichissement temporel et spatial sont utilises afin de produire une trame 
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presentable, Tinventeur a constate qu'un nouveau besoin de synchronisation 
apparalt. 

En effet, il est necessaire de synchroniser les flux avant leur decodage (et 
non pas seulement a leur presentation). Cette contrainte s'avere plus complexe 
que la synchronisation de presentation car il est necessaire d' identifier quelles 
sont les unites necessaires au decodage d'une unite afin de produire une trame 
correcte. Un seul decalage peut rendre inutile tout un flux ainsi que tous les flux 
bases sur ce dernier. II s'agit la d'un probleme nouveau, et non evident, identifie 
par l'inventeur. 

Un probleme similaire se pose Iorsqu'une unite de flux re$ue doit etre 
decodee, ou decryptee, a l'aide dMnformations (par exemple une cle de decodage) 
que le terminal aurait du recevoir, mais qu'il n'a pas revues. A nouveau, le resultat 
du decodage sera au minimum inefficace, en general nuisible (en termes de signal 
restitue), et peut conduire au blocage du terminal. Dans les deux cas, un traitement 
inutile et nefaste aura ete effectue. 

Un autre probleme important rencontre dans les systemes de diffusion 
(« multicast » ou « broadcast ») est que les memes informations doivent etre 
multidiffusees, pour permettre a un utilisateur se connectant a un instant 
quelconque de recevoir Tintegralite du ou des flux qu'il a selectionnes. Cet aspect 
specifique est deja discute dans la demande de brevet EP-01 4600462, non encore 
publiee, aux noms des titulaires de la presente demande de brevet. Selon cette 
technique, le traitement est effectue au niveau du transport, ce qui impose un 
traitement de chaque unite de flux, tenant compte des specificites des differents 
types de transport. 

L'art anterieur en matiere de representation multimedia dans des scenarii 
« broadcast » et « multicast » est decrit dans la specification du « carousel MPEG- 
4 ». Cependant un certain nombre de fonctionnalites sont interdites ou rendues 
extremement consommatrices en debit. Dans les deux scenarii de delivrance 
consideres, il est necessaire de signaler des points d'entree a la presentation 
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multimedia a tout moment. Ceci se traduit par une repetition des donnees relatives 
a la description de la scene : scene BIFS, textures. 

Des que le contenu multimedia devient riche, cette repetition simple n'est 
pas acceptable et conduit a des temps de telechargement excessifs. Par ailleurs, 
5 cette specification ne permet pas de diffuser certains elements multimedia (clips 
audio/video de courte duree). 

L'invention a notamment pour objectif de pallier ces differents 
inconvenients de l'etat de Tart. 

Plus precisement, un objectif de V invention est de fournir une technique 
10 permettant de gerer efficacement des unites de flux, lorsque celles-ci dependent 
de, ou sont liees a, une ou plusieurs autres unites de flux. 

Notamment, un objectif de l'invention est de fournir une telle technique, 
qui permette la gestion de flux lies, en particulier dans le cas de donnees codees a 
l'aide d'un codage hierarchique, ou un codage comprenant un codage associant 
15 des donnees de base et des donnees d'enrichissement. 

Un autre objectif de l'invention est de fournir une telle technique, 
permettant d'assurer efficacement la gestion du decodage, ou du decryptage, 
d'unites de flux. 

Encore un autre objectif de T invention est de fournir une telle technique, 
20 qui permette d'optimiser la transmission de scenarii multidiffuses, et notamment 
de reduire la quantite de ressource utilisee, sans reduire la qualite de la reception. 

L'invention a pour objectif, en d'autres termes, d'optimiser les traitemenls 
*- effectues, dans les terminaux, tant en quantite qu'en qualite. 

Ces objectifs, ainsi que d'autres qui apparaitront par la suite, sont atteints 
25 selbn I' invention a l'aide d'un procede de transmission d'au moins tin flux de 
donndes vers au moins un terminal, le ou lesdits flux etant organises en unites de 
flux. Selon l'invention, au moins certaines desdites unites de flux comprennent au 
moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux, de fagon & optimiser les traitements dans ledit terminal et/ou le debit 
30 utile du ou desdits flux. 
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On dispose ainsi d'un systeme de synchronisation logique, permettant de 
faciliter !a gestion des unites de flux, de limiter les traitements dans les terminaux, 
d'ameliorer la qualite de restitution,... 

Le format de donnees ainsi defini, selon V invention, peut etre mis en 
5 oeuvre non seulement pour la transmission et la reception de flux, mais egalement 
pour leur diffusion, leur enregistrement et leur stockage. 

Selon un aspect avantageux de Finvention, qu'au moins un desdits 
pointeurs pointe vers au moins une unite de flux dudit flux ou d'un autre flux 
susceptible d'avoir ete regue precedemment dans un terminal, dite unite anterieure 
10 necessaire, de fagon qu'un traitement de ladite unite de flux ne soit pas effectue, 
dans ledit terminal, si la ou lesdites unites anterieures necessaires n'ont pas ete 
regues. 

Cet aspect de l'invention repose en effet notamment sur V identification du 
probleme nouveau de la synchronisation « arriere » des flux ou des unites de flux, 

15 et sur I' observation non evidente que la solution la plus efficace est de ne pas 
traiter les unites de flux lorsque Ton ne dispose pas de tous les elements pour le 
faire. II apparait en effet preferable, en termes de restitution de signal, d'ignorer 
une unite de flux plutot que d'en effectuer un decodage qui conduira a une 
deterioration du signal restitue, voire a un blocage complet du terminal. 

20 De fa$on avantageuse, le procede de Finvention comprend la transmission 

d'au moins deux flux de donnees transmis separement, une unite de flux d'un 
premier flux pointant vers au moins une unite anterieure necessaire d'au moins un 
second flux, ladite unite de flux du premier flux comprenant des donnees 
d'enrichissement des donnees contenues dans le ou lesdits seconds flux. 

25 Dans ce cas, lesdits flux de donnees peuvent avantageusement 

correspondre a des niveaux hierarchiques differents d'un codage hierarchique, le 
traitement d'une unite de flux d'un niveau hierarchique donne n'etant effectue que 
si les unites de flux du ou des niveaux hierarchiques inferieurs correspondants ont 
ete regus. 

30 Ladite unite de flux peut pointer sur au moins une unite anterieure, 
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definissant une sequence d'unites anterieures necessaires. 

Selon une caracteristique avantageuse de I' invention, au moins un desdits 
pointeurs permet de retrouver au moins une unite anterieure necessaire 
comprenant des donnees permettant le decodage et/ou le decryptage de 1' unite de 
5 flux consideree. 

Preferentiellement, la ou lesdites unites anterieures necessaires 
comprennent des donnees permettant a un terminal de decider si Ies donnees 
d'une unite de flux consideree doivent etre decodees et/ou decryptees, puis 
affichees apres decodage. 
10 Selon une autre mise en oeuvre avantageuse, au moins un desdits pointeurs 

pointent vers des donnees susceptibles d'etre connues dudit terminal, de fa^on que 
ce dernier puisse decider de sa capacite ou de son incapacite a traiter 1'unite de 
flux correspondante. 

De fagon avantageuse, selon un autre aspect de I' invention, au moins une 
15 desdites unites de flux comprend au moins un pointeur pointant vers au moins une 
unite de flux dudit flux ou d'un autre flux, susceptible d'etre re?ue prochainement. 

Preferentiellement, la ou lesdites unites de flux susceptible d'etre retjue 
prochainement possede en marqueur, permettant de faire un lien avec le ou Jesdits 
pointeurs. 

20 Ainsi, avantageusement, les pointeurs d'au moins deux unites de flux 

similaires transmises a des instants distincts peuvent pointer vers une meme unite 
de flux susceptible d'etre re?ue prochainement. 

De fa?on preferentielle, le procede de l'invention met en ceuvre un 
indicateur indiquant le role du ou des pointeurs, parmi au moins deux des roles 
25 appartenant au groupe comprenant : 

- * designation d'au moins une unite de flux anterieure devant etre 
decodee' pour permettre la prise en compte de Tunite de flux 
consideree ; . 

designation d'au moins une unite de^ flux anterieure comprenant des 
30 donnees necessaires au decodage et/ou au decryptage de l' unite de 
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flux consideree, et/ou d'une reference a un etat d'un systeme de 
protection ; 

designation d'au moins une unite de flux posterieure. 
Avantageusement, au moins certaines desdites unites de flux comprennent 
5 un descripteur de dependance, definissant ledit role. 

De fa$on avantageuse, au moins certaines desdites unites de flux 
comprennent un marqueur de dependance, permettant son identification en tant 
qu'unite anterieure necessaire et/ou un marqueur d' identification de ladite unite de 
flux dans ledit flux. 

10 Preferentiellement, le precede de Tinvention est mis en oeuvre au niveau 

synchronisation, de fagon qu'aucun traitement prealable d'une unite de flux regue 
ne soit necessaire. 

L' invention concerne egalement un ou plusieurs flux de donnees transmis 
selon le procede de transmission decrit ci-dessus. Corame deja mentionne, un tel 
15 format de donnees peut etre utilise pour la transmission, la diffusion, la reception, 
l'enregistrement (par exemple via un magnetoscope ou un enregistreur de disques 
optiques) et le stockage de donnees (par exemple sur un CD-ROM, une bande, un 
serveur distant...). 

On notera egalement que l'invention permet de combiner aisement 
20 plusieurs de ces aspects. Par exemple, certains flux peuvent etre diffuses, et 
d'autres fournis sur un CD-ROM, ou un serveur, la connaissance des seconds 
etant necessaires pour decoder (ou optimiser) les premiers. 

Un tel flux de donnees est organise en unites de flux transmises 
independamment les unes des autres, au moins certaines desdites unites de flux 
25 comprenant au moins un pointeur pointant vers au moins une unite de flux dudit 
flux ou d'un autre flux, de fa^on a optimiser les traitements dans ledit terminal 
et/ou le debit utile du ou desdits flux. 

Avantageusement, au moins un desdits pointeurs pointe vers au moins une 
unite de flux dudit flux ou d'un autre flux susceptible d'avoir ete re?ue 
30 precedemment dans un terminal, dite unite anterieure necessaire, de fa?on qu'un 




traitement de ladite unite de flux ne soit pas effectue, dans ledit terminal, si la ou 
lesdites unites anterieures necessaires n'ont pas ete regues. 

L' invention concerne egalement les serveurs de donnees destinees a etre 
transmises vers au moins un terminal, sous la forme d'au moins un flux de 
5 donnees organise en unites de flux transmises independamment les unes des 
autres, au moins certaines desdites unites de flux comprenant au moins un 
pointeur pointant vers au moins une unite de flux dudit flux ou d'un autre flux, de 
faqon a optimiser les traitements dans ledit terminal et/ou le debit utile du ou 
desdits flux. 

10 L'invention concerne encore les terminaux apte a recevoir au moins un 

. flux de donnees organise en unites de flux transmises independamment les unes 
des autres, au moins certaines desdites unites de flux comprenant au moins un 
pointeur pointant vers au moins une unite de flux dudit flux ou d'un autre flux, de 
fa^on a optimiser les traitements dans ledit terminal et/ou le debit utile du ou 

15 desdits flux. 

L'invention concerne egalement les procedes de reception d'au moins ,un 
flux de donnees organise en unites de flux transmises independamment les unes 
des autres, au moins certaines desdites unites de flux comprenant au moins un 
pointeur pointant vers au moins une unite de flux dudit flux ou d'un autre flux, de 
20 fa?on a optimiser les traitements dans ledit terminal et/ou le debit utile du ou 
desdits flux. 

De fa§on avantageuse, au moins un desdits pointeurs pointe vers au moins une 
unite de flux dudit flux ou d'un autre flux susceptible d'avoir ete regue 
precedemment dans un terminal, dite unite anterieure necessaire, et le procede de 
25 reception comprend les etapes suivantes : s 
- • . « analyse du ou desdits pointeurs d'une unite de flux ; 

traitement de ladite unite de flux si la ou lesdites unites anterieures 
necessaires ont ete re?ues. 
L'invention concerne enfin les utilisations du procede de transmission, en 
30 particulier pour une des applications appartenant au groupe comprenant : 
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diffusion systematique d'un message avant acces a un programme 
selectionne par un utilisateur ; 

acces conditionnel a un niveau de qualite particulier et/ou a une 

option particuliere d'un programme ; 

television interactive. 
D'autres caracteristiques et avantages de T invention apparaitront plus 
clairement a la lecture de la description suivante d'un mode de realisation 
preferentiel de l'invention, donne a titre de simple exemple illustratif, et des 
dessins annexes, parmi lesquels : 

la figure 1 illustre le principe de la gestion de la dependance d'un 

flux de donnees par rapport a un autre, selon l'invention ; 

la figure 2 presente une mise en ceuvre de l'invention, dans le cas 

de la diffusion d'un flux (« broadcast ») et de sa reception par deux 

terminaux, sous la forme de sessions decalees dans le temps ; 

la figure 3 illustre le cas d'une synchronisation liee au decodage, ou 

au decryptage, d'une unite de flux (IPMP) ; 

la figure 4 presente une variante du cas de la figure 3, avec deux 
points de protection (decodage et rendu). 

Le mode de realisation preferentiel decrit ci-apres concerne notamment la 
transmission de flux, dans un systeme multimedia, notamment du type MPEG4. 
1. ra ppels sur la technique anterieure : 

La technique anterieure ne permet ni de prendre en compte la transmission 
efficace (en termes de debit et de fonctionnalite) de scenes multimedia dans des 
scenarii multicast ou bien broadcast ni la synchronisation de flux interdependants 
des elements lies au contenu de type clefs de controle d' acces. 
1 . 1 representation multimedia dans des scenarii broadcast et multicast 

Une solution est proposee dans la specification du « carousel MPEG-4 ». 
Cependant un certain nombre de fonctionnalites sont interdites ou rendues 
extremement consommatrices en debit. Dans les deux scenarii de delivrance 
consideres, il est necessaire de signaler des points d'entree a la presentation 




multimedia a tout moment. Ceci se traduit par une repetition des donnees relatives 
a la description de la scene : scene BIFS, textures. 

Des que le contenu multimedia devient riche cette repetition simple n'est 
pas acceptable et conduit a des temps de telechargement excessifs. Par ailleurs, 
5 cette specification ne permet pas de diffuser certains elements multimedia (clips 
audio/video de courte duree). 

Par ailleurs, dans la demande de brevet non encore publiee EP-01 
4600462, Ies donnees etaient vehiculees au niveau du transport. En revanche, 
selon F invention, le tout se trouve au niveau de la couche dite de synchronisation 

1 0 qui est independante du transport. 

Ceci a pour avantage de s'abstraire des differents types de transport et 
d'unifier les informations de synchronisation temporelle et logiques ainsi que les 
marqueurs d'acces aleatoire en un meme point, ceci permet de calculer a un 
endroit unique la decision de conserver ou pas l'unite. II s'avere que Ton connait 

15 par ailleurs bien plus d' informations sur le flux, ce qui permet de specialiser les 
decisions par type de flux (interessant pour video/audio par rapport a BIFS, etc). 
1.2 synchronisation multimedia 

L'art anterieur en matiere de synchronisation multimedia est represents 
essentiellement par les protocoles de transport bases sur RTP et par MPEG-4 

20 (Synchronization Layer). Dans Fapproche utilisee, les mechanismes de 
synchronisation ont ete principalement congus pour synchroniser temporellement 
un flux audio et un flux video, afin qu'ils soient presentes sans decalage. Ces 
informations etaient vehiculees au moyen d'un systeme d'estampillage temporel 
: (une horloge de reference, des estampilles de decodage et de presentation) 

25 Avec l'avenement de codages hierarchiques ou de differents niveaux 

d'enrichissement temporel et spatial sont utilises afin de produire une trame 
presentable, un nouveau besoin de synchronisation apparait. En effet, il est 
necessaire de synchroniser les flux avant leur decodage (et non pas seulement a 
leur presentation). Cette contrainte s'avere plus cpmplexe que la synchronisation 

30 de presentation car il est necessaire d'identifier quels sont les unites n&essaires au 
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decodage d'une unite afin de produire une trame correcte. Un seul decalage peut 
rendre inutile tout un flux ainsi que tous les flux bases sur ce dernier. Comme on 
le voit, il s'agit d'un probSeme de dependance logique entre unites a decoder. 

Un intervalle de temps reduit est deja pris en compte dans MPEG-4 video, 
5 mais celui-ci n'est pas accessible aux couches systeme. 
1.3 protection des donnees 

Un troisieme cas de synchronisation n'est pas aborde dans Tart anterieur : 
celui de la synchronisation d'un flux de protection de donnees lie a un flux 
multimedia. 

10 Dans ce cas, il est necessaire de s 'assurer que toute unite de flux 

multimedia sera decryptee avec une cle correcte avant d'etre decodee (le cas 
echeant les resultats ont toute chances d'etre catastrophiques). Des lors que les 
flux ne sont pas assures d'etre synchrones, les outils de synchronisation ne 
peuvent assurer ceci. 

15 Cette fois-ci, 1'entree du decodeur et la sa sortie sont des points de 

synchronisation (la trame decodee peut a son tour etre cryptee). 
2. principes de IMnvention 

Les buts de Finvention sont notamment de permettre : 

• La diffusion multicast et broadcast de scenes multimedia ; 
20 • La synchronisation logique du decodage multimedia. 

Ceci est obtenu a 1'aide de mecanismes de signalisation permettant 
d'atteindre ces deux objectifs : 

• Mecanisme permettant configurer un flux afin que chacune des 
unites temporelles le composant s'identifient de fa<jon 

25 parametrable. 

• Mecanisme de chainage avant pour les scenarii de 
diffusion/broadcast. 

Les elements techniques essentiels de T invention sont ainsi : 

• Elements de synchronisation logique entre elements de plusieurs 
30 flux ou dans le meme flux (video, audio, et systeme de protection 
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de donnees) ; 

• La solution permet pour chaque element du flux d'indiquer de quel 
type d'elements il depend, et de quels elements en particulier il 
depend. Plusieurs mises en oeuvre sont possibles. 

On utilise notamment, sous toute forme de realisation : 

• Descripteur de dependance : « DependencyDescriptor » ; 

• Marqueur de dependance : « DependencyMarker » 
(Optionnellement) ; 

• Pointeur sur V unite dont on depend : « DependencyPointer » ; 

• Marqueur (idendfie une unite du flux) : « marker » 
(Optionnellement). 

3. Description detaillee d'au moins un mode particulier de realisation : 

3.1 specification MPEG4 

L/annexe 1 presente de fa?on detaillee un exemple de mise en oeuvre de 
Tinvention pour des normes de type MPEG, sous la forme d'une specification 
MPEG-4. 

3.2 comportement du recepteur 

Le terminal re§oit un IOD (InitialObjectDescriptor) celui-ci fait reference 
par T intermediate de leurs descripteurs (ObjectDescriptor) a au moins un objet 
de description de scene graphique (flux BEFS : F_BIFS) et optionnellement a au 
moins un objet de description d'objets graphiques (flux d'OD : F_OD). Le 
terminal va ouvrir ces flux en se basant sur les informations presentees ci-apres. 

Chacun de ces descripteurs d'objet contient' un descripteur par flux 
elementaire (ES) qui le compose (ESDescriptor). Chaque ESDescriptor contient 
un champ dependsOnESID et un SLConfigDescriptor. 

Le champ dependsOnESID permet de construire le graphe des 
dependances entre flux identifies par leur ESID. 

L'objet SLConfigDescriptor permet de configurer les outils de 
synchronisation. 

On trouvera dans Tobjet SLConfigDescriptor la possibilite de configurer le 
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recepteur afin qiTil verifie les differentes dependances de la fa<jon suivante : 

OepesideiricyMarker //permet de configurer le 

stream afin qu'il identifie ses paquets. 
5 { 

int (5) markerLength; 

} 

DependencyDescriptor //permet de decrire les 

liens de dependance. 
10 { 

int(2) mode; // 0 : mode version par DTS, 

// 1 :mode version par ID, 
// 2 : mode scalable, 
// 3 : mode IPMP 

15 //si mode==l la dependance se fait % a un 

marqueur dans le stream. 

// si mode=3 la dependance se fait de fa§on opaque 
(le systeme IPMP se doit de 

// comprendre la dependance et de valider ou 
20 non le decodage/decryptage. 

// eventuellement en utilisant un marker. II 
s'agit done d'un code 

// qui permet au systeme de protection de 
savoir s'il s'agit ou non d'une 
25 // unite decryptable (ou non) 

// si mode==0 ou mode==2, la dependance est 
calculee sur le DTS 

// par consequent depLength = dtsLength dans 
le SLConfig correspondant. 
30 int(5) depLength; 
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if (mode==l || mode==0) 

{ ; 

int(depLength) value; //valeur de la premiere unite a 

chercher. 
} 

} 

Ainsi, un flux peut se declarer dependant d'un autre flux (lui-meme, un 
media normal ou IPMP). Dans ce cas, il decrit dans sa configuration SL comment . 
il va signaler cette dependance (Dependency descriptor) dans quatre modes 
distincts : 

3. 2. 1 Mode version par DTS et par ID ( modes 0 et I) : 

Le flux va signaler pour chacune de ces AccessUnits (AU)une 

dependance avant dans le flux lui-meme. Dans d'autres termes l'AU(n) 

precise quelle est la prochaine AccessUnit a decoder. Cette signalisation se 

fait au moyen d'un marqueur dans chaque paquet qui decrit ou bien, dans 

le mode 0 le DTS de la prochaine Access Unit (unique) ou bien FID de la 

prochaine Access Unit dans le mode 1. 

Dans ce cas on rajoute la valeur du premier element a recuperet 
II peut par exemple s'agir d'un flux BIFS en mode 

broadcast/multicast. 

3.2.2 Mode scalable (mode 2) : 

Le flux va signaler pour chacune de ces Access Units une 

dependance par rapport a un flux dont il depend. Ce flux est suppose 

unique. 

Ce principe est illustre par la figure 1. L' unite de flux 11 d'un flux 
dependant 10 comprend classiquement un en-tete (SLHeader) 111 et un 
champ de donnees (SL payload) 112. L'en-tete 111 comprend notamment 
deux pointeurs Depl et Dep2, qui definissent des liens de dependance 12 
et 13 avec des unites de flux 141 et 142 respectivement d'un flux de base 
14, dont la connaissance est necessaire pour traiter Tunite de flux 11. 
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3.2.3 Mode IPMP (mode 3) : 

Le flux va signaler pour chacune de ces AccessUnits un 
identificateur qui permet au systeme de protection de donnees de decoder 
l'unite. Celui-ci etant donne ce marqueur peut repondre si oui ou non il sait 
5 decry pter 1' unite. 

Le SLConfigDescriptor peut contenir un ou plusieurs 
DependencyDescriptor et un ou plusieurs DependencyMarker, ce qui permet de 
regler les differents cas de dependance dans le flux. (A priori un seul 
DependencyMarker suffit, mais on peut eventueliement en avoir plusieurs) 
10 Ainsi si le SLConfig contient DependencyMarker, il signalera un ID de 

version pour chacun de ses paquets (modes 1 et 3). 

Dans l'entete d'un paquet SL correspondant a une AccessUnit on trouvera 

done : 

• Pour chaque dependencyMarker du SLConfigDescriptor, un 
1 5 marker de longueur markerLength. 

• Pour chaque DependencyDescriptor un dependencyPointer de 
longueur depLength. 

Une fois ces differents marquages realises, le systeme est a meme de : 
a) Fonctionner en mode « broadcast » grace aux modes 0 et 1 ; 
20 b) Gerer les dependances de scalabilite ; 

c) Gerer les dependances IPMP ; 
et les combinaisons de a),b),c). 

3.3 Description du fonctionnement en mode IPMP 

Lors de la reception de FObjectDescriptor relatif a un objet, le terminal 
25 examine le SLConfigDescriptor pour chacun des flux associes. Ceci permettra de 
decoder l'entete des paquets SL pour chacun des flux : en particulier de decoder 
les marqueurs. 

Dans le cas IPMP il y aura des DTS et/ou des dependencyPointer, ainsi 
que cela est illustre en figure 3. 
30 Pour chaque AU du flux, avant que celui-ci ne soit decode, il est traite par 
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le systeme IPMP 32, en lui fournissant au moins les donnees suivantes identifiant 
de flux ESID, DTS, dependency Pointer (IPM) 31. Le systeme IPMP repond alors 
(33) s'ii est en mesure de traiter (decrypter) l'AU, en considerant 1' information 
311 (Code Dec) relative au decodage. Si ce n'est pas le cas et que le DTS de 
5 1* unite est arrive a maturite, l'AU est detruite (34). On n'essaie done pas de 
decoder des AU non coherentes. 

Dans l'exemple de la figure 4, on retrouve d'une part les elements de la 
figure 3, et d' autre part un traitement lie a la restitution de Fimage, apres son 
decodage 41. En effet, a l'aide du champ 312 (CodeComp), on peut transmettre 
10 des donnees relatives a la composition, tel que l'ajout d'un tatouage ou d'un 
. message sur 1' image. Si le systeme de protection de donnees 32 ne sait pas gerer 
cette composition (il ne sait pas afficher 1' image (42)), par exemple parce que le 
decodeur ne dispose par du tatouage requis, Pimage n'est pas affichee (43). 

On peut egalement prevoir que la trame sera marquee par exemple d'un 
15 logo, qui disparait si le decodeur dispose de la bonne cle. 

3.4 Description du fonctionnement en mode multicast/broadcast . 
Ce fonctionnement est illustre en figure 2, qui presente ; 
le flux emis 21 ; 

le flux re9u par un premier recepteur (session 1) 22 ; 
20 - le flux rcqu par un premier recepteur (session 2) 23. 

La session 1 demarre sur le paquet 211, puis prend en compte l'unite de 
flux 213, sur lequel pointe (24) Funite de flux 211, puis Tunite de flux 215, selon 
le lien 25. 

N La session 2, entamee legerement apres, demarre avec l'unite de flux 212, 

25 qui pointe (26) sur l'unite de.flux 214. 

Selon I'invention, deux (pu plus) unites de flux peuvent 'pointer sur une 
meme unite de flux suivante. C'est le mecanisme de fusion 27 : les unites de flux 
213 et 214 pointent toutes deux sur l'unite de flux 215. Ainsi, bien qu'ayant 
debutees a des instants differents, les deux sessions utilisent, apres une phase « de 

30 rattrapage, les memes unites de flux 215. Cela permet clairement d'ameliorer le 
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rendement. 

On decrit plus precisement ce fonctipnnement. 

Lors de la reception de 1'ObjectDescriptor, le terminal examine le 
SLConfigDescriptor pour chacun des flux associes. Ceci permettra de decoder 
5 Tentete des paquets SL pour chacun des flux : en particulier de decoder les 
marqueurs. 

Dans le cas Multicast/Broadcast il y aura des done des DTS, au moins un 
dependency Pointer en mode 0 ou 1, et un marqueur (mode 1 « par ID ») . Le 
terminal sait done quelle est la premiere unite a recuperer pour chacun des flux. II 
10 essaiera done de recuperer la premiere unite correspondant a chaque flux. 

S 'il re?oit la premiere unite, alors il peut commencer a afficher le contenu. 
Chaque unite decrit dans le « dependencyPointer » la prochaine unite a recevoir et 
le DTS/marqueur identifie chaque unite de fa<jon unique. 

Si le terminal ne re^oit pas la premiere unite (il peut s'en rendre compte ou 
15 bien par time-out ou des qu'il re§oit une unite pour ce flux de type RAP=1 qui ne 
correspond pas au marqueur souhaite). II se deconnecte (fermeture complete de 
session) et essaie de se reconnected 

On notera que ce mecanisme prend en compte la fusion de sessions. 
On notera egalement que le mode par ID est necessaire des que Ton ne sait 
20 pas a Tavance le DTS de la prochaine unite. 

Ce mecanisme est utilise notamment pour BIFS,OD,Textures, clips audio, 
clips video dans MPEG -4. Pour la video/audio streamee il ne sera pas utilise. 
3.5 Description du fonctionnement en mode scalable 

Lors de la reception de FObjectDescriptor, le terminal examine le 
25 SLConfigDescriptor pour chacun des flux associes. Ceci permettra de decoder 
Tentete des paquets SL pour chacun des flux . Pour de la video scalable, un flux 
servira de base et un ou plusieurs autres flux dependront de celui-ci. Chaque flux 
dependant du flux de base declarera un DependencyDescriptor. 

Pour chaque AU du flux d'amelioration, il referencera grace au 
30 dependencyPointer les DTS des AU du flux de base dont il depend. 
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Dans la plupart des cas, il y aura deux dependencyPointer dans le flux 
d'amelioration afin de pointer sur les deux AU de reference de la video de base. 
3.6 Description du fonctionnement en mode broadcast+IPMP 

Dans ce cas, le BIFS, par exemple contiendra deux dependencyDescriptor 
5 dans la configuration SL. L/un pour le mode broadcast, Tun pour IPMP. II 
contiendra un marqueur si le mode broadcast est par ID. 
4. Exemples duplications : 

4. 1 Diffusion d'une publicite avant de commencer un programme 

Dans de nombreux cas de streaming sur Internet, les fournisseurs de 
10 contenu envoient systematiquement une publicite avant d'envoyer le contenu lui- 
meme. Les scenarii internet etant unicast (client-serveur), cela se fait en deux 
phases : telechargement de la publicite, la fin de la publicite declenche le 
lancement du streaming de la video. 

Dans un scenario multicast ou broadcast, ou Ton ne peut avoir recours a un 
15 fonctionnement client-serveur, il n*y a pas de notion de requete, de ce fait, 
l'utiiisateur n'a generalement acces qu'a Tetat courant de la presentation. 

Grace au mecanisme de reference avant ce scenario devient possible en 
multicast ou bien en broadcast. 

En effet, il est possible d'envoyer de fa?on cyclique la publicite et de 
20 fusionner vers le programme en cours en fin de publicite. 

Ceci permet de s'assurer par exemple que tout utilisateur visualisera la 
publicite au debut (Pendant ce temps la, on peut realiser le telechargement du 
contenu pour la suite de fa?on efficace et incrementale)f 

Des applications du meme type peuvent etre, pour chaque film diffuse, une 
25 notification de la categorie du film (accord parental, moins de 16 ans, etc.). 

4.2 Acces conditionnel scalable , 

L'idee ici est d'envoyer le meme flux (unique) video et audio pouvant etre 
visualise de fa?on differente en fonction des droits des utilisateurs. La 
signalisation des dependances des trames video. par rapport aux cles de protection 
30 permet de decoder uniquement celles dont on a la cle. On peut done decoder 
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toutes les images pour celui qui possede toutes Ies cles, _ des images pour un 
utilisateur ayant moins de droits, etc... Ceci permet de faire de Faeces 
conditionnel de fayon plus echelonnable.(echelonnelabilite tempore ici) 

Le scenario, plus complexe, et plus utile est celui ou Ton a plusieurs flux 
5 et ou I'on peut jouer a la fois sur Fechelonnabilite temporelle et en resolution 

Avec ce systeme de dependance par trame, il est done possible de moduler 
de fa?on quasi-continue l'acces aux medias. 

On peut done imaginer que certains utilisateurs auraient des cles 
permettant de recevoir le son sur 5 voies (son spatialise) et d'autres uniquement le 
10 son stereo. Ce qui permettrait egalement une facturation plus fine. . . 
4.3 Television Interactive MPEG-4 

Au lieu de considerer que Tapplicatif de la « set- top box » est statique, on 
peut considerer que tout cet applicatif est une application MPEG-4 qui permet 
d'atteindre les differentes chaines (mecanisme d'inline). Cette application MPEG- 
15 4 serait active 24h/24h et permettrait de reconfigurer completement les interfaces 
graphiques, etc... 

La technique de diffusion de scene permettrait de telecharger efficacement 
I' interface graphique (BIFS/Textures/OD) ainsi que la partie applicative (MPEG- 
J). 

20 Ceci permet un deploiement/redeploiement rapide. 
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1. Definitions 

1.1 Unite de flux (AU : Access UniO 

Une unite de donnees accessible individuellement dans un flux elementaire 
(elementary stream). Une unite de flux (ou unite d'acces) est la plus petite entite a 
laquelle une information temporelle peut etre attribute. 

1.2 Objet Audiovisuel 

Une representation d'un objet naturel ou synthetise (virtuel) qui se 
manifeste de fa?on auditive et/ou visuelle. La representation correspond a un 
noeud ou a un groupe de nocuds dans la description- de la sequence B1FS. Chaque 
objet audiovisuel est associe a zero, un ou plusieurs flux elementaires (elementary 
streams) utilisant un ou plusieurs descripteurs d' objet (object descriptors). 

1.3 Sequence Audiovisuelle (AV Scene) 

Une serie d'objets audiovisuels avec des informations decrivant la scene 
qui definissent leurs attributs spatiaux et temporels incluant les fonctionnements 
resultant de 1'objet et des interactions de Tusager. 
I A Format Binaire de Scene (BIFS) 

Une representation codee d'un format de description de scene 
parametrique. 
1,5- Terminal 

Un systeme qui envoie ou regoit et presente la representation codee d'une 
scene audiovisuelle interactive comme definit par ISO/IEC 14496-1. Cela peut 
etre un systeme autonome ou partie d'un systeme d' application se soumettant a 



ISO/IEC 14496. 



2, 



Abreviations et symboles 



AU 



Unite d' Acces, ou Unite de Flux (Access Unit) 
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AV Audiovisuel (Audio-visual) 

BIFS Format Binaire de Scene (Binary Format for Scene) 

CM Memoire de Composition (Composition Memory) 

CTS Estampille Temporelle de Composition (Composition Time Stamp) 

CU Unite de Composition (Composition Unit) 

DAI Interface d' Application DMIF (voir ISO/IEC 14496-6) (DMIF Application Interfac 

DB Memoire Tampon de Decodage (Decoding Buffer) 

DTS Estampille Temporelle de Decodage (Decoding Time Stamp) 

ES Flux Elementaire (Elementary Stream) 

ESI Interface de Flux Elementaire (Elementary Stream Interface) 

ESID Identifiant de Flux Elementaire (Elementary Stream Identifier) 

FAP Parametres d* Animation Faciale (Facial Animation Parameters) 

FAPU Unites FAP (FAP Units) 

NCT Tables de Codage de Nceuds (Node Coding Tables) 

NDT Nceud de Donnee Type (Node Data Type) 

OCI Informations sur le Contenu de FObjet (Object Content Information) 

OCR Reference d'Horloge Objet (Object Clock Reference) 

OD Descripteur d' Objet (Object Descriptor) 

ODID Identifiant de Descripteur d' Objet (Object Descriptor Identifier) 

OTB Base de Temps Objet (Object Time Base) 

PLL Boucle a Verrouillage de Phase (Phase Locked Loop) 

QoS Qualite de Service (Quality of Service) 

SDM Modele de Decodeur de Systeme (System Decoder Model) 

SL Couche de Synchronisation (Synchronization Layer) 

SL-Packet Paquet de la Couche de Synchronisation (Synchronization Layer Packet) 

SPS Flux de SL-Packets (SL-Packetized Stream) 

STB Base de Temps Systeme (System Time Base) 

TTS Texte vers Parole (Text-To-Speech) 

URL Localisateur de Ressources Universelles (Universal Resource Locator) 

VOP Plan d'objets vid6o (Video Object Plane) 
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VRML Langage de Modelisation de Realite Virtuelle (Virtual Reality Modeling Langua; 

3. Configuration d'en tete de paquet SL 

3.1 Syntaxe 

class SLConf igDescriptor extends BaseDescriptor : bit (8) 
tag=SLConf igDescrTag { 
bit (8) predefined; 
if (predef ined==0) { 

bit(l) useAccessUnitStartFlag; 

bit(l) useAccessUnitEndFlag; 

bit(l) useRandomAccessPointFlag; 

bit (1) ha sRandomAccess Unit sOnly Flag, - 

bit(l) usePaddingFlag; 

bit(l) useTimeStampsFlag; 

bit(l) useldleFlag; 

bit<l) durationFlag; 

bit (32) timeStampResolution; 

bit (32) OCRResolution; 

bit (8) timeStampLength; // must be < 64 
bit (8) OCRLength; // must be < 64 

bit (8) AU__Length; // must be < 32 

bit (8) instantBitrateLength;- 
bit(4) degradationPriorityLength; 
bit (5) AU_seqNumLength; // must be < 16 
bit (5) packetSeqNumLeng.th; // must be < 16 
bit (2) extension_field_control; 

v ,. .. } 

if " (durationFlag) { 
bit (32) timeScale; 
bit (16) accessUnitDuration; 
bit ( 16) compo sit ionUnit Duration ; 

} 

if ( ! useTimeStampsFlag) ( 

bit (timeStampLength) staftDecodingTimeStamp; 
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bit ( timeStampLength) startCompositionTimeStamp; 

} 

if (hasNextAU) { 

bit (timeStampLength) nextDecodingTimeStamp; 

5 } 

if (exten5ion_f ield_control==OblO) 
{ 

MarkerDescriptor [0..1] markerDescr iptors ; 

DependencyDescriptor [0..255] dependencyDescriptors; 

10 ) 

dependencyMarkersCount=0 ; 

while (true) 

{ 

1 5 bi t < 1 ) hasMoreMarkers ; 

if (fhasMoreMarkers) break; 

DependencyMarker dependencyMarkers [dependencyMarkersCoun t + + ] ; 

20 } 

dependencyDescriptorCount =0; 

while (true) 
( 

25 bit(l) hasMoreDependencyDescriptor ; 

if (! hasMoreDependencyDescriptor) break; 

DependencyDescriptor dependencyDe scrip tor 
[dependencyDescriptorCount++] ; 

30 } 
} 

3.2 Semantique 

L'entete de paquet SL peut etre configure selon les besoins de chaque flux 
61ementaire individual. Les parametres qui peuvent etre selectionnes comprennent 
35 la presence, la resolution et la precision des estampilles temporelles et des 
references d'horloge. Cette flexibilite permet, par exemple, une faible 
augmentation du contenu de l'entete de paquet SL. 

Pour chaque flux elementaire, la configuration est transmise dans un 



SLConf igDescriptor, qui fait partie du ES_Descr iptor associe a un 
descripteur d'objet. 

Les parametres configurables dans Fentete de paquet SL peuvent etre 
divises en deux classes : ceux qui s'appliquent a chaque paquet SL (par exemple 
5 OCR, sequenceNumber) et ceux qui sont strictement apparentes aux unites 
d'acces (par exemple : estampilles temporelles, accessUnitLength, instantBitrate, 
degradationPriority). 

La colonne - predefined - permet de fixer par defaut les valeurs. 
d'un ensemble de parametres predefinis comme detaille ci-dessous. Ce tableau 
10 pourra etre mis a jour par amendements a ISO/IEC 14496 pour inclure les 
. configurations predefinies comme exige par les futurs profils. 



Tableau 1 - Vue d'ensemble des valeurs SLConf igDescriptor 

predefinies 



Champ de valeur 
predefini 


Description 


0x00 


Clientele (custom) 


0x01 


Entete de paquet SL nulle 


0x02 


Reserve a Tusage dans les fichiers MP4 


0x03 -OxFF 


Reserve a l'usage ISO 



Tableau 2 - Detail des valeurs SLConfigDescriptor predefinies 



Champ de valeur predefini 


0x01 


0x02 


UseAccessUnitStartFlag 


0 


o y';" 


UseAccessUnitEndFlag 


0 


0 


UseRandomAccessPointFlag 


.0 


0 


Use Padding Flag 


0 


0 


UseTimeS tamps Flag 


0 


1 


UseldleFlag 


0 


0 
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DurationFlag 


0 


0 


TimeStampResolution 


1000 


- 


OCRResolution 


- 


- 


TimeS tampLength 


32 


0 


OCRlength 


- 


0 


AU_length 


0 


0 


InstantBitrateLength 




0 


DegradationPriorityLength 


0 


0 


AU_seqNumLength 


0 


0 


PacketSeqNumLength 


0 


0 




Champ de valeur predefini 


0x01 


0x02 


UseAccessUn it Start Flag 


0 


0 


UseAccessUnitEndFlag 


0 


0 


UseRandomAccess Point Flag 


0 


0 


UsePaddingFlag 


0 


0 


UseTimeStampsFlag 


0 


1 


UseldleFlag 


0 


0 


DurationFlag 




0 


TimeS tampResolut ion 


1000 




OCRResolution 






TimeS tampLength 


32 


0 


OCRlength 




0 


AU_length 


0 


0 


InstantBitrateLength 




0 


DegradationPriorityLength 


0 


0 


AU seqNumLength j 


0 


0 


PacketSeqNumLength 


0 


0 
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TimeScale 






AccessUnit Duration 






Compos itionUnit Duration 






StartDecodingTimeStamp 






Star tCompositionTimeS tamp 







useAccessUnitStartFlag - indique que le 
accessUnitStartFlag est present dans chaque entete de paquet SL de ce 
flux elementaire. 

5 useAccessUnitEndFlag - indique que le accessUni tEndFlag 

est present dans chaque entete de paquet SL de ce flux elementaire. 

Si ni useAccessUnitStartFlag ni useAccessUnitEndFlag 
ne sont actifs, cela implique que chaque paquet SL correspond a une unite d'acces 
complete. 

10 useRand'omAccessPointFlag - indique que le 

RandomAccessPointFlag est present dans chaque entete de paquet SL de 

ce flux elementaire. 

hasRandomAccessUnitsOnlyFlag - indique que chaque paquet 
SL correspond a un point d'acces aleatoire. Dans ce cas, le 
15 randomAccessPointFlag n' a pas besoin d'etre utilise. 

usePaddingFlag - indique que le paddingFlag est present dans 
chaque entete de paquet SL de ce flux elementaire. 

us eTime Stamps Flag - indique que les estampilles temporelles sont 
utilisees pour la synchronisation de ce flux elementaire. Elles sont transportees 
20 dans 4 les entete de paquet SL. Sinon, les parametres accessUni tRate, 
composi t ionUni tRate, StartDecodingTimeStamp et 
startCompositionTimeStamp transportes dans cet entete de paquet SL 
doivent etre utilises pour la synchronisation. 

L'utilisation d'estampilles temporelles de depart et de duree 
25 (useTimeStampsFlag=0) est faisable uniquement sous certaines conditions, 
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incluant un environnement sans erreur. L'acces aleatoire n'est pas aise. 

useldleFlag - indique que ,idle Flag est utilise dans ce flux 
elementaire. 

durationFlag - indique que la duree constante des unites d'acces et 
5 des unites de composition pour ce flux elementaire est signalee ulterieurement. 

timeStampResolution - est la resolution des estampilles temporelles 
en impulsions par seconde. 

OCRResolution - est la resolution de la base temporelle de Tobjet en 
cycles par seconde. 

10 t imeStampLength - est la longueur des champs d'estampille 

temporelle dans les entete de paquet SL. timeStampLength doit prendre des 

valeurs entre zero et 64 bits. 

OCRlength - est la longueur du champ ob j ectClockRef erence 

dans Tentete de paquet SL. Une suite de zeros indique qu'aucun 
15 obj ectClockRef erences n'est present dans ce flux elementaire. Si 

OCRstrearnFlag est mis, OCRLength doit etre zero. Sinon, OCRlength 

doit prendre des valeurs entre zero et 64 bits. 

AU__Length - est la longueur des champs accessUnitLength dans 

Tentete de paquet SL pour ce flux elementaire. AU__Length doit prendre une 
20 valeur entre zero et 32 bits. 

instantBitrateLength - est la longueur du champ 

instantBitrate dans Tentete de parquet SL pour ce flux elementaire. 

degradat ionPr ior ityLength - est la longueur du champ 

degradationPriority dans Tentete de paquet SL pour ce flux elementaire. 
25 AU__seqNumLength - est la longueur du champ 

AU_sequenceNumber dans Tentete de paquet SL pour ce flux elementaire. 

packetSeqNumLength - est la longueur du champ 

packet SequenceNumber dans Tentete de paquet SL pour ce flux 

elementaire. 

30 timeScale - est utilise pour exprime la duree des unites d'acces et des 
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unites de composition. Une seconde est egalement divisee en parties 
timeScale. ; 

acce s sUnit Dura t ion - la duree d'une unite d'acces est 
accessUnitDuration * 1/timeScale secondes. 
5 compos it ionUnitDuration - la duree d'une unite de composition 

est compositionUnitDuration * 1/timeScale secondes. 

startDecodingTimeStamp - transporte le temps auquel la premiere 
unite d'acces de ce flux elementaire doit etre decode. II est transporte dans la 
resolution specifiee par timeStampResolution. 
10 startCompositionTimeStamp - transporte le temps auquel Tunite 

. de composition correspondant a la premiere unite d'acces de ce flux elementaire 
doit etre decode. II est transporte dans la resolution specifiee par 
timeStampResolution. 

extension_field_control - Ce champs permet d'etendre le SL. 
15 La valeur OlbO indique que les descripteurs doivent se trouver a la fin du 
SLConfigDescriptor. 

marker Descriptors - Cette table indique une description de 
marqueurs pour identifier les unites d'acces suivantes dans le flux ^ 
dependencyDescriptors - Cette table indique les descripteurs de 
20 dependance specifiant comment referencer soit les unites d'acces precedentes soit 
les unites a venir. 
4> M arkerDescriptor 

La syntaxe est la suivante : 

25 class MarkerDescriptor extends BaseDescriptor : bit (8) . » V' 

tag=DependencyMarkerTag { 

int(5) encodedMarkerLength; L •• 
MarkerLength- encodedMarkerLength +1; 

} 

30 



5. DependencyDescriptor 

5.1 syntaxe 
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abstract class DependencyDes crip tor extends BaseDescriptor { 
}; 

class SimpleDependencyDescriptor extends BaseDescriptor : bit (8) 
5 tag=SimpleDependencyTag { 
bit (2) mode; 

bit (5) dependencyLength; 
if (mode=^l [ I mode==0) 
{ 

10 bit (dependencyLength) firstvalue; 

} 

} ; 

class CompleteDependencyDescriptor extends BaseDescriptor : bit (8) 
tag=CompleteDependencyTag { 
bit (2) mode; 
bit (16) ESID ; 
bit (5) dependencyLength; 
if (mode==l I I mode==0) 
{ 

int (dependencyLength) firstvalue; 

) 

} ; 

25 5.2 semantique 
5.2.1 mode 

Quatre modes sont definis : 

• Mode 0 : reference vers Favant par DTS. 

• Mode 1 : reference vers Tavant par Marqueur. 
30 • Mode 2 : reference arriere de scalabilite. 

• Mode 3 : mode IPMP. 

Les modes 0 et 1 forcent chaque unite d'acces a faire reference a la 
prochaine unite d'acces. 

Le mode 2 force chaque unite d'acces a faire reference a Tunite d'acces 
35 precedente qui est necessaire pour decoder cette unite d'acces. (Note : Dans de 



15 



20 
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nombreux cas, plus de deux dependencydescriptors sont necessaires, pour 
se referer a deux unites d'acces necessaires pu plus). 

Le mode 3 permet a chaque unite d'acces de contenir un identifiant 
opaque, qui peut etre utilise par le systeme IPMP, afin de decider si le decodage 
5 et la composition de cette unite d'acces est possible. 

Les modes 1 et 3 requierent un MarkerDescriptor dans le flux. 
5.2.2 ESID 

Ce champ optionnel identifie le flux auquel le DependencyDescriptor fait 
reference. 

10 Pour SimpIeDependencyDescriptor, ESID est calcule de la maniere 

. suivante : 

• Modes 0 et 1 : le flux courant. 

• Mode 2 : selon dependsOnESID 

• Mode 3 : pas applicable. 

15 dependencyLength - est la longueur, soit du marqueur (si il existe) soit 

du decodingTimeStamp. 

value - est la valeur du premier marqueur ou dts identifiant la prochaine 
unite d'acces a decoder 

6. Specification de Tentete de paquet SL 

20 6.1 Syntaxe 

aligned (8) class SL_PacketHeader (SLConf igDescriptor SL) { 
if (SL. useAccessUnitStartFlag) 
bit(l) accessUnitStartFlag; 
if (SL. useAccessUnitEndFlag) 
25 , \ bit (1) accessUnitEndFlag; 

ifv (SL.OCRLength>0) , * ^ ' 

bit (1) OCRflag; / : 
if (SL.use-IdleFlag) 
bit(l) idleFlag; 
30 if (SL. usePaddingFlag) . 

bit(l) paddingFlag; 
if (paddingFlag) 

bit (3) paddingBits; 
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f (!idleFlag ( ! paddingFlag II paddingBi ts ! =0 ) ) { 

if (SL. packetSeqNumLength>0) 

bit (SL . packetSeqNumLength) packetSequenceNumber ; 
if (SL. degradationPriorityLength>0) 

bit (1) DegPriof lag; 
if (DegPriof lag) 

bit (SL.degradationPriorityLength) degradationPriori ty 
if (OCRflag) 

bit (SL.OCRLength) objectClockRef erence; 

if (accessUnitStartFlag) { 

if (SL . useRandomAccessPointFlag) 

bit(l) randomAccessPointFlag; 
if (SL. AU_seqNumLength >0) 

bit (SL. AU_seqNumLength) AU_sequenceNumber ; 
if (SL.useTimeStampsFlag) { 

bit(l) decodingTimeStampFlag; 

bit (1) compositionTimeStampFlag; 

) 

if (SL. instantBitrateLength>0) 

bit(l) instantBitrateFlag; 
if (decodingTimeStampFlag) 

bit (SL. timeStampLength) decodingTimeStamp; 
if (compositionTimeStampFlag) 

bit (SL. timeStampLength) compositionTimeStamp; 
if (SL.AU_Length > 0) 

bit (SL.AU_Length) accessUnitLength ; 

if (instantBitrateFlag) 

bit (SL. instantBitrateLength) instantBitrate; 

} 

f (SL.hasMarker && beginningOf AU () ) 

for (int 1=0; I< markerDescriptorCount; I++) 
{ 

bit (marker . length) markerValue 
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> 

} 

for (int 1=0; I< dependencyDescriptorCount; I++) 
{ 

5 if (dependencyDescriptor .mode>>l == 0) 

{ 

bit (dependencyDescriptor [I ] .depLength) dependencyPoin terValue ; 

} 

} 

10 } 

6.2 Semantique 

access UnitStartFlag - quand il vaut un, indique que le premier 
octet de la charge de ce parquet SL est le depart d'une unite d'acces. Si cet 
15 element de syntaxe est omis de la configuration- de Tentete de paquet SL, sa 
valeur par defaut est connue du paquet SL precedent suivant la regie suivante : 

accessUnitStartFlag = (le paquet SL precedent a 
accessUnitEndFlag=l) ? 1 : 0. 

accessUnitEndFlag - quand il vaut un, indique que le dernier octet 
20 de la charge du paquet SL est le dernier octet de V unite d'acces en cours. Si cet 
element de syntaxe est omis de la configuration de Tentete de paquet SL, sa 
valeur par defaut est uniquement connue apres reception du paquet SL suivant la 
regie suivante : 

accessUnitEndFlag = (le paquet SL suivant a 
25 accessUnitStartFlag==l) ? 1 : 0. 

Si ni AccessUnitStartFlag ni AccessUnitEndFlag ne sont 
configures dans I'entete de paquet SL, cela implique que chaque paquet SL 
correspond a une seule unite d'acces, d'ou chaque accessUnitStartFlag = 
accessUnitEndFlag = 1. 
30 On notera, quand Tentete de paquet SL est configure pour utiliser 

accessUnitStartFlag mais ni accessUnitEndFlag ni 
accessUnitLength, il n'est pas garanti que le terminal puisse determiner la 
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fin d'une unite d'acces avant que la suivant ait ete re?ue. 

OCRf lag - quand il vaut un, indique qu'un objectClockRef erence 
va suivre. La valeur par defaut pour OCRf lag est zero. 

idle Flag - indique que ce flux elementaire sera inactif (c'est-a-dire 
5 absence de donnees utiles) pour un laps de temps indetermine. Ce signe peut etre 
utilise par le decodeur pour faire la distinction entre une absence deliberee et une 
absence due a une erreur de paquets SL suivants. 

paddingFlag - indique la presence de remplissage dans ce paquet SL. 
La valeur par defaut pour paddingFlag est zero. 
10 paddingBits - indique le mode de donnees de remplissage a utiliser 

dans ce paquet SL. La valeur par defaut pour paddingBits est zero. 

Si paddingFlag est mis et paddingBits vaut zero, cela indique 
que la charge suivante de ce paquet SL consiste uniquement en octets de 
remplissage. accessUnitStartFlag, randomAccessPointFlag et 
15 OCRf lag ne doivent pas etre mis si paddingFlag est mis et paddingBits est 
zero. 

Si paddingFlag est mis et paddingBits est superieur a zero, cela 
indique que la charge de ce paquet SL est suivie par des paddingBits, formes 
de bits a zero pour Falignement des octets de la charge. 

20 packetSequenceNumber - s'il est present, il doit etre augmente 

continuellement pour chaque parquet SL comme un compteur modulo. Une 
discontinuite au decodeur correspond a un ou plusieurs paquets SL manquants. 
Dans ce cas, une erreur doit etre signalee a la couche de synchronisation. Si cet 
element de syntaxe est omis de la configuration de Fentete de paquet SL, le 

25 controle de la continuite des unites de flux par la couche de synchronisation ne 
peut pas etre accomplie pour ce flux elementaire. 

Duplication des paquets SL : les flux elementaires qui ont un champ 
sequenceNumber dans leurs entetes de paquet SL doivent utiliser la 
duplication des paquets SL pour la recuperation des erreurs. Le(s) paquet(s) SL 

30 dupliques doivent immediatement suivre l'original. Le packet 
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SequenceNumber des paquets SL dupliques doit avoir la meme valeur et 
chaque octet du paquet SL original doit etre duplique, a l'exception d'un champ 
ob j ectClockRef erence, si present, qui doit encoder une valeur valide pour 
le paquet SL duplique. 

degPrioFlag - quand il vaut un, indique que 

degradationPriority est present dans ce paquet. 

degradat ionPriority - indique Timportance de la charge de ce 
paquet SL. Le streamPriority definit la priorite de base d'un ES. 
degradationPriority definit une baisse de priorite pour ce paquet SL par 
rapport a la priorite de base. La priorite pour ce paquet SL est donnee par : 

SLJPacketPriority = streamPriority -degradationPriority 

degradationPriority reste a cette valeur jusqu' a la prochaine 
occurrence. Cette indication peut etre utilisee par le decodeur du flux elementaire 
ainsi que par 1'adaptateur pour une instance d'une couche de distribution 
spdcifique. La proportion de la degradation parmi les paquets SL de differents 
flux elementaires augmente au fur et h mesure que SLJPacketPriority diminue. 

obj ectClockRef er en ce - contient une estampille temporelle objet. 
La valeur temporelle OTB t est reconstruite a partir de cette estampille temporelle 
OCR selon la formule suivante: 

t = (ob jectClockRe'f erence/SL . OCRResolut ion) + 
k * (2 SL.ocRLen gt h /SL ^ 0 CRRe solu t ion) 

ou k est le temps que le compteur ob j ectClockRef erence a couvert. 

obj ectClockRef erence est seulement present dans Pent6te de 
paquet SL si OCR flag est mis. 

II est possible de transporter uniquement une valeur OCR sans charge a 
T interieur d'un paquet SL. 

La suite presente la semantique des elements de syntaxe qui sont 
seulement presents au debut d'une unite d'acces quand signale explicitement par 
accessUnitStartFlag dans le flux binaire 

randomAccessPointFlag - quand il vaut un, indique que Faeces 
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aleatoire au contenu de ce flux elementaire est possible. 
randomAccessPointFlag doit uniquement etre mis si 
accessUnitStartFlag est mis. Si cet element de syntaxe est omis de la 
configuration de l'entete de paquet SL, sa valeur par defaut est la valeur de 
5 SLConfigDe scrip tor . has RandomAccessUni t sOnly Flag pour ce 
flux elementaire. 

AU_sequenceNumber - si present, il doit etre augmente 
continuellement pour chaque unite d'acces comme un compteur modulo. Une 
discontinuity au decodeur correspond a une ou plusieurs unites d'acces 
10 manquantes. Dans ce cas, une erreur doit etre signalee a Tutilisateur de la couche 
synchronisation. Si cet element de syntaxe est omis de la configuration de Pentete 
de paquet SL, le controle de la continuite des unites de flux par la couche 
synchronisation ne peut pas etre execute pour ce flux elementaire. 

Duplication des unites d'acces : les unites d'acces envoyees utilisant le 
15 meme nombre de sequences que l'AU immediatement precedente doivent etre 
ignorees. Une telle unite d'acces dupliquee, dont Foriginal n'avait pas RAP mis, 
mais l'unite dupliquee oui, permet Fajout de points d'acces aleatoire dans un flux 
emis, permettant a des clients d'entrer dans le flux a des points definis, pendant sa 
transmission, pendant que d'autres clients re£oivent deja le flux. 
20 decodingTimeStampFlag - indique qu'une estampille temporelle de 

decodage est presente dans ce paquet. 

compositionTimeStampFlag - indique qu'une composition 
d'estampille temporelle est presente dans ce paquet. 

accessUni tLengthFlag - indique que la longueur de cette unite 
25 d'acces est presente dans ce paquet. 

ins tantBi trateFlag - indique qu'un instan tBitrate est 
present dans ce paquet. 

decodingTimeStamp - est une estampille temporelle de decodage 
comme configure dans le SLConf igDescriptor associe. Le temps de 
30 decodage td de cette unite d'acces est reconstruit a partir de cette estampille 
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temporelle de decodage selon la formule : 

td = (decodingTimeStamp/SL. timeStampResolution + k * 
2 sl. times tam P Length /SL ^ timeStampResolution 

ou k est le temps que le compteur decodingTimeStamp a englobe. 
5 Un decodingTimeStamp doit uniquement etre present si le temps 

decodeur est different de la composition temporelle pour cette unite d'acces. 
compos itionTimeS tamp - est une composition d'estampille temporelle 
comme configure dans le SLConf igDescriptor associe. La. 
composition temporelle tc de la premiere unite de composition resulte du fait que 
10 cette unite d'acces est reconstruite a partir de cette composition d'estampille 
. temporelle selon la formule : 

td = (compositionTimeStamp/SL. timeStampResolution + 
k * 2 SL timeStampLength /SL. timeStampResolution - : , 
ou k est le temps que le compteur compositionTimeStamp a englobe. 
15 accessUnitLength - est la longueur de l'unite d'acces en octets. Si 

cet element de syntaxe n'est pas present ou a la valeur zero, la longueur de 1'unite 
d'acces est inconnue. 'j: 

instantBitrate - est le taux binaire instantane en bits par secondcde 
ce flux elementaire jusqu'a ce que le prochain champ instantBitrate soit 
20 trouve. 

markerValue - est la valeur d'un marqueur qui permet d'identifier 
l'unite d'acces. Ce marqueur est defini si mar kerDescriptor s existe. 

DependencyPointerValue - est un indice de DTS ou d'un marqueur 
' comme definit par le DependencyDescriptor. 
25 MarkerDescriptorCount : le nombre de descripteurs de marqueurs. 

be pendency Descriptor Count : le nombre de descripteurs 
dependants. • ~ 4 - - - 1 

7. semantique de decodage 
7.1 Mecanisme de reference avant (modes 0 et 1) 
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Le SLConf igDescriptor associe a un ES, indique la premiere unite 
d'acces qui permet d'entrer dans le flux. 

Si le mode de reference est DTS, alors le SLConfigDescriptor doit contenir 
un decodingTimeStamp. 
5 Sinon, un marqueur est utilise pour marquer chaque unite d'acces. 0 et -1 

ont une signification speciale : 

// 0 signifie qu'aucune autre unite d'acces suivra, 
//-lsignifie que n'importe quelle unite d'acces peut etre utilisee. 
Chaque unite d'acces doit contenir un marqueur et un dependencypointer 
10 permettant a chaque unite d'acces d'indiquer la prochaine unite d'acces. 

7.2 Mecanisme de reference arriere (mode 2) 

Le SLConfigDescriptor definira n descripteurs de type 
DependencyDescriptor, qui indiqueront les unites d'acces dans l'ES auquel se 
refere ESID. 

15 Chaque unite d'acces du flux courant pointera les unites d'acces sur l'ES 

dont l'identifiant est ESID appele ES_base au moyen de DependencyPointers en 
reference aux unites d'acces de ES_base (identifie par ESID) a travers leur DTS. 

7.3 Mode IPMP (mode 3) 

Les DependencyPointers sont transmis au systeme IPMP avant decodage. 
20 Ces pointeurs opaques permettent aux moyens IPMP de decider s'il est possible 
ou non de decoder I'unite d'acces. II peut repondre negativement si les clefs n'ont 
pas ete re§ues, ou si les droits ne le permettent pas. Ce pointeur de dependance 
est lie a 1'unite de composition apres decodage. 

II reviendra au systeme IPMP avant composition, les moyens IPMP 
25 decidant ensuite si 1'unite peut etre ou non presentee. 

JL Flux de reference horloge 

Un flux elementaire de streamType = ClockReferenceStream doit etre 
declare au moyen du descripteur d'objet. II est utilise dans le but de transporter les 
30 estampilles temporelles de reference d'horloge objet. De multiples flux 
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elementaires dans un ensemble de nom peuvent faire reference a un tel 
ClockReferenceStream au moyen de I'elejnent de syntaxe OCR_ES_ID dans Ie 
SLConf igDescriptor pour eviter la transmission repetee de l'information 
de reference horloge. Notons, cependant, que des references circulates entre les 
flux elementaires utilisant OCR_ES_ID ne sont pas permises. 

Sur la couche de synchronisation, un ClockReferenceStream est realise en 
configurant la syntaxe de Tentete de paquet SL pour ce flux empaquete au niveau 
SL de telle maniere que seules les valeurs OCR des OCRresolution et 
OCRlength requis sont presents dans Tentete de paquet SL. 

II n'y a aucune charge de paquet SL presente dans un flux empaquete-SL 
de streamType = ClockReferenceStream. 

Dans le DecoderConf igDescriptor pour un flux de reference 
horloge, Ob.j ectTypelndication doit etre mis sur 'OxFF', 
hasRandomAccessUnitsOnlyFlag sur un et buf f erSizeDB sur W. 

La suite indique les valeurs recommandees pour le 
SLConf igDescriptor d'un flux de reference horloge : 

Table 3 - SLConfigDescriptor valeurs des parametres SLConfigDescriptor d'uh" 



pour un ClockReferenceStream 



use AccessUnitS tart Flag 


0 


useAccessUnitEndFlag 


0 


useRandomAccess Point Flag 


0 


usePaddingFlag 


0 


useTimeS tamps Flag 


0 


useldleFlag 


0 


durationFlag 


0 


times tampResolut ion 


0 


times tampLength 


0 


AU_length 


0 


degradation Priori tyLength 


0 
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AU_seqNumLength 



9. Restricdonis potmir des flux clememitaires parfagearct le meme objet de 
base ieeiporeBle 

Lorsqu'il est possible de partager un objet de base temporelle entre 
5 plusieurs flux elementaires a travers OCR_ES_ID, un nombre de restrictions pour 
Faeces a ces flux elementaires et a leur traitement existent, comme suit : 

Quand plusieurs flux elementaires partagent un simple objet de base 
temporelle, les flux elementaires sans information de reference horloge objet 
integree ne doivent pas etre utilises par le terminal, meme s'ils sont 
10 accessibles, jusqu'a ce que le flux elementaire transportant l'information de 

reference horloge objet devienne accessible. 

Si un flux elementaire sans information de reference horloge objet integree est 
rendu disponible au terminal apres le flux elementaire transportant 
F information de reference horloge objet, il doit etre delivre en 
15 synchronisation avec le(s) autre(s) flux. Notons que cela implique qu'un tel 

flux ne doive pas etre delivre depuis son debut, en fonction de la valeur 
courante de F objet de base temporelle. 

Quand un flux elementaire transportant une information de reference horloge 
objet devient indisponible ou est utilise par ailleurs (par exemple en pause) 
20 tous les autres flux elementaires qui utilisent le meme objet de base 

temporelle doivent suivre cette approche, e'est-a-dire devenir indisponibles 
ou etre manipules dans le meme sens. 

Lorsqu'un flux elementaire sans information de reference horloge objet integree 
devient indisponible, cela n'a pas d' incidence sur les autres flux 
25 elementaires qui partagent le meme objet de base temporelle. 

10, Utilisation des options de configuration pour les references d'horloge 
et les valeurs d'estampilles temporelles 
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10.1 Resolution de i'ambigu'rte dans la recuperation cTun objet de base 
tempo relle 

Du fait de la longueur limitee des valeurs obj ectClockRef erence 
ces estampilles temporelles peuvent etre ambigues. La valeur temporelle OTB 
5 peut etre reconstruite chaque fois qu'un obj ectClockRef erence est 
transmis dans les entetes d'un paquet SL selon la formule suivante : 
WB_ rc constRictcd = (° b j ectClockRef erence/SL . OCRResolution) + 
k*(2 SL - OCRLen ^ th /SL.OCRResolution) 

avec k etant une valeur entiere indiquant le nombre de boucles. La base 

10 temporelle resultante to TB ^^^est mesuree en secondes. 

Quand le premier obj ectClockRef erence pour un flux elementaire 
est acquis, la valeur k doit etre mise a un. Pour chaque occurrence suivante de 
obj ectClockRef erence la valeur k est estim£e corame suit : 

Le terminal doit comprendre des moyens pour estimer la valeur de l'objet 

15 de base temporelle a chaque instant. 

Chaque fois qu'un obj ectClockRef erence est re$u, la valeur 
estimee courante de l'OTB t OTBcstimatcd doit etre echantillonnee. Alors, t 0TB r ^(k) est 
evalue pour differentes valeurs de k. La valeur k qui minimise le terme | eslimaled 
- toTB^rccC^)! doit etre consideree comme la valeur correcte de t {mjmattMed . Cette 

20 valeur doit etre utilisee comme un nouvel apport au mecanisme d'estimation de 
Tobjet de base temporelle. 

L'application doit garantir que cette procedure produit une valeur non 
ambigue de k en selectionnant une longueur et une resolution appropriees de 
Telement obj ectClockRef erence et une frequence suffisamment elevee 

25 des valeurs d'insertion de obj ectClockRef erence dans le flux elementaire. 
Les choix pour ces valeurs dependent de la gigue de delivance pour les paquets 
SL ainsi que de 1'ecart maximum prevu entre les horloges du terminal 
transmetteur et receveur. 

10.2 Resolution de Tambiguite dans la recuperation de Testampille temporelle 
30 Du fait de la longueur limitee des valeurs decodingTimeStamp et 
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composi tionTimeStamp ces estampilles temporelles peuvent devenir 
ambigues, comme le montre la formule suivante : 
tJmMTimeStamp/SL.timeStan^^ 
SL . timeStampResolution) 
5 avec TimeStamp etant soit un decodingTimeS tamp soit un 
composi tionTimeStamp et m etant une valeur entiere indiquant le nombre 
de boucles. 

La valeur correcte de Festampille temporelle peut etre estimee 

comme suit : 

10 Chaque fois qu'un TimeStamp est requ, la valeur estimee courante de 

TOTB t OTB cstimated doit etre echantillonnee. ym) est evalue pour differentes valeurs 
de m. La valeur m qui minimise le terme | t OTB eslimated - ^(m)! est consideree 
comme la valeur correcte de t timeslamp . 

L' application peut choisir, separement pour chaque flux elementaire 

15 individuel, la longueur et la resolution des estampilles temporelles, afin de 
respecter ses exigences sur le positionnement non ambigu des evenements 
temporels. Ce choix depend du temps maximum pendant lequel un paquet SL 
avec un TimeStamp peut etre envoye, apres le moment indique par le 
TimeStamp, ainsi qu'a la precision demandee au positionnement temporel. 

20 10.2 remarques sur V usage des references d'horloge objet et des estampilles 
temporelles 

La ligne temporelle d'une base de temps objet permet de distinguer deux 
instants separes par plus d'l/SL.OCRResolution . OCRResolution doit 
etre choisi suffisamment grand pour obtenir la precision dont a besoin 
25 Fapplication pour synchroniser un ensemble de flux elementaires. 

Les estampilles temporelles et de composition permettent de distinguer 
deux instants separes par plus d'l/SL . timeStampResolution . 
timeStampResolution doit etre choisi suffisamment grand pour obtenir la 
precision dont a besoin l'application en terme de reperage des unites d'acces pour 
30 un flux elementaire donne. 
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Un TimeStampResolution plus eleve que le OCRResolution ne 
permettra pas d'obtenir une meilleure discrimination entre les evenements. Si 
TimeStampResolution est plus faible que le OCRResolution, les 
evenements pour ce flux specifique ne peuvent pas etre reperes avec la precision 
maximum possible avec ce OCRResolution donne. 

Le parametre OCRLength est signale dans la configuration de Fentete 
SL. 2 SL 0CRLcngth /SL. OCRResolution est Fintervalle de temps couvert par 
le compteur ob j ectClockReference avant qu'il boucle. OCRLength doit 
etre choisi suffisamment eleve pour respecter les besoins de Fapplication pour un 
positionnement non ambigu des evenements temporels pour un ensemble de flux 
elementaires. 

Lorsqu'une application connait la valeur k definie plus haut, la ligne 
temporelle OTB est claire pour chaque valeur temporelle. Quand 1' application ne 
peut pas reconstruire le facteur k, comme par exemple dans une application qui 
permet Faeces aleatoire sans information complementaire, la ligne temporelle 
OTB est ambigue modulo 2 SL OCRLength /SL . OCRResolution. Ainsi, chaque 
estampille temporelle se referant a cet OTB est ambigue. il peut, cependant, etre 
considere clair a Finterieur d'un environnement d'application a trayers la 
connaissance de la gigue maximum supposee et des contraintes sur la duree 
pendant laquelle une unite d'acces peut etre envoyee avant son instant de 
decodage. 

Notons que les flux elementaires qui choisissent un intervalle de temps 
2 sl. timestampLenguy SL ^ t i m e S t a mpR e s o l'U 1 1 o n , superieur que 
2sl. ocRLength^ SL QCRRe s o 1 u t i on ne peuvent reperer de fa?on non ambigue 
les evenements temporels que dans le plus petit des deux intervalles. 

Dans certains cas, lorsque k et m ne peuvent etre estimes correctement, le 
modele tampon peut etre transgresse, ce qui entraine des operations et des 
resultats imprevisibles du decodeur. 

Par exemple, si on considere une application qui veut synchroniser les flux 
elementaires avec une precision d'l ms, OCRResolution doit etre choisi egal ou 
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superieur a 1000 (le temps entre deux impulsions successives de l'OCR est alors 
egal a 1ms). Supposons OCRResolution=2000. 

L'application suppose une gigue entre le STB et le OTB de 0.1% (c'est-a- 
dire 1ms par seconde). Les horloges doivent par consequent etre ajustes au moins 
5 chaque seconde (c'est-a-dire, dans le pire des cas, que les horloges auront devie 
d'lms, ce qui est la contrainte de precision). Supposons que des 
objectClockRef erence sont envoyes chaque Is. 

L'application veut avoir une ligne temporelle OTB claire de 24h sans avoir 
besoin de reconstruire le facteur k. Le OCRLength est alors choisi en 
1 0 consequence de meme que 2 SL * OCRLen <? th / s L . OCRRe s o 1 u t i on=24h . 

Supposons maintenant que l'application veut synchroniser les evenements 
a l'interieur d'un flux elementaire seul avec la precision de 10 ms. 
TimeStampResolution doit etre choisi egal ou superieur a 100 (le temps 
entre deux impulsions successives du Time Stamp est alors egal a 10ms). 
15 Supposons TimeStampResolution=200. 

L'application veut etre capable d'envoyer les unites d'acces a un 
maximum d'une minute avant leur temps decodeur ou de composition. Le 
timeStampLength est alors choisi comme 

2SL timestam P Length /SL ^ tirne s tampResolut ion = 2 minutes. 
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REVINDICATIONS 

1. Procede de transmission d'au moins un flux de donnees vers au moins un 
terminal, le ou lesdits flux etant organises en unites de flux, 

caracterise en ce qu'au moins certaines desdites unites de flux comprennent au 
5 moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux, de fa?on a optimiser les traitements dans ledit terminal et/ou le debit 
utile du ou desdits flux. 

2. Procede de transmission selon la revendication 1, caracterise en ce qu'au 
moins un desdits pointeurs pointe vers au moins une unite de flux dudit flux ou 

10 d'un autre flux susceptible d'avoir ete regue precedemment dans un terminal, dite 
. unite anterieure necessaire, 

de fagon qu'un traitement de ladite unite de flux ne soit pas effectue, dans ledit 
terminal, si la ou lesdites unites anterieures necessaires n'ont pas ete regues. 

3. Procede de transmission selon la revendication 2, caracterise en ce qu'il 
15 comprend la transmission d'au moins deux flux de donnees transmis separement, 

une unite de flux d'un premier flux pointant vers au moins une unite anterieure 
necessaire d'au moins un second flux, ladite unite de flux du premier flux 
comprenant des donnees d'enrichissement des donnees contenues dans le ou 
lesdits seconds flux. 

20 4. Procede de transmission selon la revendication 3, caracterise en ce que 
lesdits flux de donnees correspondent a des niveaux hierarchiques differents d'un 
codage hierarchique, le traitement d'une unite de flux d'un niveau hierarchique 
donne n'etant effectue que si les unites de flux du ou des niveaux hierarchiques 
inferieurs correspondants ont ete regus. 

25 5, Procede de transmission selon Tune quelconque des revendications 3 et 4, 
caracterise en ce que ladite unite de flux pointe sur au moins une unite anterieure, 
defmissant une sequence d' unites anterieures necessaires. 

6. Procede de transmission selon Tune quelconque des revendications 2 a 5, 
caracterise en ce qu'au moins un desdits pointeurs permet de retrouver au moins. 
30 une unite anterieure necessaire comprenant des donnees permettant le decodage 
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RE VEND! C ATI ONS 

1. Procede de transmission d'au moins un flux de donnees vers au moins un 
terminal, le ou lesdits flux etant organises en unites de flux, 

caracterise en ce qu'au moins certaines desdites unites de flux comprennent au 
moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux susceptible d'avoir ete re?ue precedemment dans un terminal, dite unite 
anterieure necessaire, 

de fa9on qu'un traitement de ladite unite de flux ne soit pas effectue, dans ledit 
terminal, si la ou lesdites unites anterieures necessaires n'ont pas ete re?ues. 

2. Procede de transmission selon la revendication 1, caracterise en ce qu'il 
comprend la transmission d'au moins deux flux de donnees transmis separement, 
une unite de flux d'un premier flux pointant vers au moins une unite anterieure 
necessaire d'au moins un second flux, ladite unite de flux du premier flux 
comprenant des donnees d'enrichissement des donnees contenues dans le ou 
lesdits seconds flux. 

3. Procede de transmission selon la revendication 2, caracterise en ce que 
lesdits flux de donnees correspondent a des niveaux hierarchiques differents d'un 
codage hierarchique, le traitement d'une unite de flux d'un niveau hierarchique 
donne n'etant effectue que si les unites de flux du ou des niveaux hierarchiques 
inferieurs correspondants ont ete regus. 

4. Procede de transmission selon Tune quelconque des revendi cations 2 et 3, 
caracterise en ce que ladite unite de flux pointe sur au moins une unite anterieure, 
definissant une sequence d' unites anterieures necessaires. 

5. Procede de transmission selon Tune quelconque des revendications 1 a 4, 
caracterise en ce qu'au moins un desdits pointeurs permet de retrouver au moins 
une unite anterieure necessaire comprenant des donnees permettant le decodage 
et/ou le decryptage de T unite de flux consideree. 

6. Procede de transmission selon la revendication 5, caracterise en ce que la 
ou lesdites unites anterieures necessaires comprend des donnees permettant a un 
terminal de decider si les donnees d'une unite de flux consideree doivent etre 
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et/ou le decry ptage de P unite de flux consideree. 

7. Procede de transmission selon la revendication 6, caracterise en ce que la 
ou lesdites unites anterieures necessaires comprend des donnees permettant a un 
terminal de decider si les donnees d'une unite de flux consideree doivent etre 
decodees et/ou decryptees, puis affichees apres decodage. 

8; Procede de transmission selon Tune quelconque des revendications 1 a 7, 
caracterise en ce qu'au moins un desdits pointeurs pointent vers des donnees 
susceptibles d'etre connues dudit terminal, de fagon que ce dernier puisse decider 
de sa capacite ou de son incapacity a traiter P unite de flux correspondante. 
9. Procede de transmission selon Tune quelconque des revendications 1 a 8, 
caracterise en ce qu'au moins une desdites unites de flux comprend au moins un 
pointeur pointant vers au moins une unite de flux dudit flux ou d'un autre flux, 
susceptible d'etre regue prochainement. 

10- Procede de transmission selon la revendication 9, caracterise en ce que la 
ou lesdites unites de flux susceptible d'etre regue prochainement possede en 
marqueur, permettant de faire un lien avec le ou lesdits pointeurs. 

11. Procede de transmission selon Tune quelconque des revendications 9 eMO, 
caracterise en ce que les pointeurs d'au moins deux unites de flux similaires 
transmises a des instants distincts pointent vers une meme unite de flux 
susceptible d'etre regue prochainement. 

12. Procede de transmission selon Tune quelconque des revendications I a 1 1, 
caracterise en ce qu'il met en ceuvre un indicateur indiquant le role du ou des 
pointeurs, parmi au moins deux des roles appartenant au groupe comprenant 

- designation d'au moins une unite de flux anterieure devant etre 
decodee pour permettre la prise en compte de Punite de flux 
^consideree ; 

designation d'au moins une unite de flux anterieure comprenant des 
donnees necessaires au decodage et/ou au decry ptage de 1' unite de 
flux consideree, et/ou d'une reference a un etat d'un systeme de 
protection ; 
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decodees et/ou decryptees, puis affichees apres decodage. 

7. Procede de transmission selon Tune quelconque des revendications 1 a 6, 
caracterise en ce qu'au moins un desdits pointeurs pointent vers des donnees 
susceptibles d'etre connues dudit terminal, de fa<jon que ce dernier puisse decider 
de sa capacite ou de son incapacite a traiter V unite de flux correspondante. 

8. Procede de transmission selon Tune quelconque des revendications 1 a 7, 
caracterise en ce qu'au moins une desdites unites de flux comprend au moins un 
pointeur pointant vers au moins une unite de flux dudit flux ou d'un autre flux, 
susceptible d'etre regue prochainement. 

9. Procede de transmission selon la revendication 8, caracterise en ce que la 
ou lesdites unites de flux susceptible d'etre regue prochainement possede en 
marqueur, permettant de faire un lien avec le ou lesdits pointeurs. 

10. Procede de transmission selon Tune quelconque des revendications 8 et 9, 
caracterise en ce que les pointeurs d'au moins deux unites de flux similaires 
transmises a des instants distincts pointent vers une meme unite de flux 
susceptible d'etre re^ue prochainement. 

11. Procede de transmission selon Tune quelconque des revendications 1 a 10, 
caracterise en ce qu'il met en ceuvre un indicateur indiquant le role du ou des 
pointeurs, parmi au moins deux des roles appartenant au groupe comprenant : 

designation d'au moins une unite de flux anterieure devant etre 
decodee pour permettre la prise en compte de 1'unite de flux 
consideree ; 

designation d'au moins une unite de flux anterieure comprenant des 
donnees necessaires au decodage et/ou au decryptage de 1' unite de 
flux consideree, et/ou d'une reference a un etat d'un systeme de 
protection ; 

designation d'au moins une unite de flux posterieure. 

12. Procede de transmission selon la revendication 1 1, caracterise en ce qu'au 
moins certaines desdites unites de flux comprennent un descripteur de 
dependance, definissant ledit role. 
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designation d'au moins une unite de flux posterieure. 
13. Procede de transmission selon la reyendication 12, caracterise en ce qu'au 
moins certaines desdites unites de flux comprennent un descripteur de 
dependance, definissant ledit role. 
5 14. Procede de transmission selon Tune quelconque des revendications 1 a 13, 
caracterise en ce qu'au moins certaines desdites unites de flux comprennent un 
marqueur de dependance, permettant son identification en tant qu'unite anterieure 
necessaire. 

15. Procede de transmission selon Tune quelconque des revendications 1 a 14, 
10 caracterise en ce qu'au moins certaines desdites unites de flux comprennent un 

. marqueur d' identification de ladite unite de flux dans ledit flux. 

16. Procede de transmission selon Tune quelconque des revendications 1 a 15, 
caracterise en ce qu'il est mis en ceuvre au niveau synchronisation, de fagon 
qu'aucun traitement prealable d'une unite de flux reque ne soit necessaire. 

15 17. Flux de donnees transmis selon le procede de transmission de Tune 
quelconque des revendications 1 a 16. 

18. Flux de donnees transmis vers et/ou requ par au moins un terminal, et 
organise en unites de flux transrnises independamment les unes des autres, 
caracterise en ce qu'au moins certaines desdites unites de flux comprennent au 

20 moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux, de fa$on a optimiser les traitements dans ledit terminal et/ou le debit 
utile du ou desdits flux. 

19. Flux de donnees selon la revendication 18, caracterise en ce qu'au moins 
Vun desdits pointeurs pointe vers au moins une unite de flux dudit flux ou d'un 

25 autre flux susceptible d'avoir ete regue precedemment dans un terminal, dite unite 
anterieure necessaire, • 

de fa^on qu'un traitement de ladite unite de flux ne soit pas effectue, dans ledit 
terminal, si la ou lesdites unites anterieures necessaires n'ont pas ete regues. 

20. Serveur de donnees destinees a etre transrnises vers au moins un terminal^ 
30 sous la forme d'au moins un flux de donnees organise en unites de flux transrnises 
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13. Procede de transmission selon Tune quelconque des revendications 1 a 12, 
caracterise en ce qu'au moins certaines desdites unites de flux comprennent un 
marqueur de dependance, peimettant son identification en tant qu'unite anterieure 
necessaire. 

5 14. Procede de transmission selon Tune quelconque des revendications 1 a 13, 
caracterise en ce qu'au moins certaines desdites unites de flux comprennent un 
marqueur d'identification de ladite unite de flux dans ledit flux. 

15. Procede de transmission selon Tune quelconque des revendications 1 a 14, 
caracterise en ce qu'il est mis en oeuvre au niveau synchronisation, de fa<jon 

10 qu'aucun traitement prealable d'une unite de flux re§ue ne soit necessaire. 

16. Flux de donnees transmis selon le procede de transmission de Tune 
quelconque des revendications 1 a 15. 

17. Flux de donnees transmis vers et/ou requ par au moins un terminal, et 
organise en unites de flux transmises independamment les unes des autres, 

15 caracterise en ce qu'au moins certaines desdites unites de flux comprennent au 
moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux susceptible d'avoir ete re?ue precedemment dans un terminal, dite unite 
anterieure necessaire, 

de fagon qu'un traitement de ladite unite de flux ne soit pas effectue, dans ledit 
20 terminal, si la ou lesdites unites anterieures necessaires n'ont pas ete revues. 

18. Serveur de donnees destinees a etre transmises vers au moins un terminal, 
sous la forme d'au moins un flux de donnees organise en unites de flux transmises 
independamment les unes des autres, 

caracterise en ce qu'au moins certaines desdites unites de flux comprennent au 
25 moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux susceptible d' avoir ete re9ue precedemment dans un terminal, dite unite 
anterieure necessaire. 

19. Terminal apte a recevoir au moins un flux de donnees organise en unites 
de flux transmises independamment les unes des autres, 

30 caracterise en ce qu'au moins certaines desdites unites de flux comprennent au 
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independamment les unes des autres, 
caracterise en ce qu'au moins certaines desdites unites de flux comprennent au 
moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux, de fa§on a optimiser les traitements dans ledit terminal et/ou le debit 
utile du ou desdits flux. 

21. Terminal apte a recevoir au moins un flux de donnees organise en unites 
de flux transmises independamment les unes des autres, 

caracterise en ce qu'au moins certaines desdites unites de flux comprennent au 
moins un pointeur pointant vers au moiris une unite de flux dudit flux ou d'un 
autre flux, de fagon a optimiser les traitements dans ledit terminal et/ou le debit 
utile du ou desdits flux. 

22. Procede de reception d'au moins un flux de donnees organise en unites de 
flux transmises independamment les unes des autres, 

caracterise en ce qu'au moins certaines desdites unites de flux comprennent au 
moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux, de fagon a optimiser les traitements dans ledit terminal et/ou le debit 
utile du ou desdits flux. 

23. Procede de reception selon la revendication 22, caracterise en ce qu'au 
moins un desdits pointeurs pointe vers au moins une unite de flux dudit flux ou 
d'un autre flux susceptible d'avoir ete regue precedemment dans un terminal, dite 
unite anterieure necessaire, 

et en ce qu'il comprend les etapes suivantes : 

analyse du ou desdits pointeurs d'une unite de flux ; 

traitement de ladite unite de flux si la ou lesdites unites anterieures 

necessaires ont ete regues. 

24. Utilisation du procede de transmission selon Tune quelconque des 
revendications 1 a 16 pour une des applications appartenant au groupe 
comprenant : 

diffusion systematique d'un message avant acces a un programme 
selectionne par un utilisateur ; 
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moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux susceptible d'avoir ete re?ue precedemment dans un terminal, dite unite 
anterieure necessaire. 

20. Procede de reception d'au moins un flux de donnees organise en unites de 
5 flux transmises independamment les unes des autres, 

caracterise en ce qu'au moins certaines desdites unites de flux comprennent au 
moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux susceptible d' avoir ete re$ue precedemment dans un terminal, dite unite 
anterieure necessaire. 

10 21. Procede de reception selon la revendication 20, caracterise en ce qu'au 
moins un desdits pointeurs pointe vers au moins une unite de flux dudit flux ou 
d'un autre flux susceptible d' avoir ete regue precedemment dans un terminal, dite 
unite anterieure necessaire, 
et en ce qu'il comprend les etapes suivantes : 

15 - analyse du ou desdits pointeurs d'une unite de flux ; 

traitement de ladite unite de flux si la ou lesdites unites anterieures 
necessaires ont ete re9ues. 
22. Utilisation du procede de transmission selon Tune quelconque des 
revendications 1 a 15 pour une des applications appartenant au groupe 

20 comprenant : 

diffusion systematique d'un message avant acces a un programme 
selectionne par un utilisateur ; 

acces conditionnel a un niveau de qualite particulier et/ou a une 
option particuliere d'un programme ; 
25 - television interactive. 
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acces conditionnel a un niveau de qualite particulier et/ou a une 
option particuliere d'un programme ; 
television interactive. 



Modifiee le 1 3/05/02 
* 














AU 




CIS 


Dip I 


IX 1 i2 







I M SLHatkr 



SLPuykcckAU 



Snuim 



"2. 









AU 




CIS 




, ► 



SLiixtkr 



j t 



Base 

|i/ 2. Soeam 



D 
T 



S S 



c 

T 



AU 



t 




D 


c 


N 




AU 


T 


T 


E 






S 


S 


X 

r 







D 
T 



C f* 
T 
S 



1 



T 



AU 



LA 



( 



AU 



Sic< 



D 


C 


N 




AU 


T 


T 


E 
X 

r 






S 


S 







Fusion 



D 


c 


N 




AU 


T 


T 


E 






S 


S 


X 
T 







D 
T 



C 
T 

S 



21 



D 


c 


N 




AU 






D 


c 


N 




AU 


T 


T 


E 










T 


T 


E 






S 


S 


X 
T 










S 

-it— 


S 


X 
T 










tj 




2'f 


D 


c 


N 




AU 


T 


T 


E ! 






S 


S 


X 
T 







2/5 



D 


c 


N 




AU 


T 


T 


E 






S 


S 


X 

r 







regue le 1 3/05/02 




• 'tfjitaffi frfde o 



S1J-L 
i 


r 


GxJeQr 


QxfcCbnp 



T 
5/1 



1er depot 

^1 O 



Modifiee le 1 3/05/02 







I 


..... 


AU 


BTTS 


CIS 


P 










r 













i 




AU 




DIS 


CIS 


p 












M 







Ruxdb 
cutcnu 




Ch jetle r unite. 
Mftre a jour ['euadu gesaonnoim En 
particulicr GxfcDcc pcul cxrtenir le nont*e 
d: trames a i cnorer a purtirdeceirara^ 



3^ 













0IS 


CIS 


p 










M 








DECODER 



CIS 



I 

p 

M 



CU 

(ercr>ptaV 
wutarrarkirg) 



QxbCorrp 



\ 

52. 



Oijtftc Tunitd 

rratiuiier GxleDtt: pent ccnicmr le naiiie | 
cb trarrcs a i^T^ajxrlirdecenxrirrL ^ 



cu 

Cante 




regue le 1 3/05/02 



2/4 




ZD 
< 



HI X h 



o 


h- co 


Q 


h- CO 




ZD 




< 






~2L LI 


J X I — 


O 


I — CO 


Q 


I- CO 



3 
< 



lUIXh 
O h- CO 



CO 



CM 



regue le 13/05/02 



3/4 



3 



CO 
h- 
O 



h- 
Q 



< 



Q_ 

CO 
I— 

o 

CO 

h- 

Q 



X 



CD 



u_ 8 



on 








)tecti 


ceva 


le flu 


ntes 




CD 


CO 










CO 


de 


nees 


da 


pre 


Q) 


cles 


CD 


E 


c 

n 


C 


Syste 


de d< 


des ' 


no 





C\J 

T— 

CO 



> 



CD 

■a 

CD 

X 

i 

CO 



CO 



CO 



CD 

■a 
as 

CD 

X 
—I 

CO 



CL 

£ 
o 
O 

CD 

"a 
o 
O 



e 
o 



CD 



CD 03 
CD 



O 



C CD 

en * 



•a rf 

en .»= 

•*— ' <— 
+-* ~ 

CD O 



tr c: 
03 o 
Ql o _ 

fill 

a) § o 
O -2 ~ 



CO 

CD 
CD 




CO 




CO 

Ll. 



regue le 13/05/02 






r 












— CL 




cn 




\- 




o 




CD 




\- 
Q 





«-egue le 28/03/02 




latTITUT 
HAltQJtAL DS 

:r;cuiis:iiLi 



BREVET D1NVENTION 
CERTIFICAT D'UTILITE 

Code de la propriety intellectuelle - Livre VI 



N° 11235*02 



DEPARTE^ENT DES BREVETS 

26 fc:s. mo de Sa nt Petersbaurg 
75ECO Paris Cedex 08 

Telephone : 01 53 04 53 04 Telecopie : 01 42 93 59 30 



DESIGNATION DMNVENTCUR(S) Page N° }../}.. 
(Si le demandeur n'est pas I'inventeur ou Tunrque inventeur) 



Cet imprime est a remplir lisiblement a Tencre noire 



C3 113W/250S99 



^cs iref ere?tces sjoacr ce dossier 
(factiltalif) 



7879 



H° D'ENREGISTREEVIENT NATIONAL 



TITRE DE L' INVENTION (200 caracteres ou es paces maximum) 
Procede de transmission de flux dc donnees, flux de donnees, serveur, terminal, precede de reception et utilisation correspondents 



LE(S) DEMANDEUR(S) : 




FRANCE TELECOM 
6, place d'AHeray 
75015 PARIS 




DESIGNE(NT) EN TANT QU'INVENTEUR(S) : (Indiquez en haut a droite «Page N° 1/la S'il y a plus de trois inventeurs, 
utilisez un formulaire identique et numerotez chaque page en indiquant le nombre total de pages). 


Nom 


COTARMANACH 


Prenoms 


Alexandre 


Adresse 


Rue 


3, rue Paul Bert 




Code postal et viile 


35000 RENNES 


Societe d'appartenance (facultatij) 




Nom 




Prenoms 




Adresse 


Rue 






Code postal et ville 


1 


Societe d'appartenance (facultatij) 




Nom 




Prenoms 




Adresse 


Rue 






Code postal et vilie 


1 


Societe d'appartenance (facultatif) 




DATE ET SIGNATURE(S) 
DU (DES) DEMANDEUR(S) 
OU DU MANDATAIRE 
(Nom et qualite du signataire) 

Lc S mars 2002 

P. VIDON Mandatairc CPI 92- 1 250 * 







La loi n°78-17 du 6 janvier 1978 relative a I'informatique, aux fichiers et aux liberies s'applique aux reponses faites a ce formulaire. 
Elle garantit un droit d'acces et de rectification pour les donnees vous concernant aupres de HNPI. 



